Report a security vulnerability in nacos to bypass authentication #4593
Comments
|
该agent用于服务间通信鉴权白名单, 既然是白名单模式,就必然是忽略鉴权。 由于是服务端之间使用,就是不推荐用户直接使用,因此不会在文档进行描述。 你这个问题就像nacos的默认管理员密码是nacos一样,因此你的修复建议无法采纳。 当然如果有更好的,不影响性能且不影响服务端间通信的修复方案,欢迎提出。 |
|
这个忽略鉴权,最大的问题是,没有在文档说明,对于大部分使用者来说,根本不知道会存在这样的一个机制(不看源码都不知道),虽说不推荐用户使用,但是这个机制默认就已经存在,等于是在用户毫不知情的情况下使用了,用户都不知道,何谈推荐不推荐呢。 我认为这个问题和nacos的默认密码是不一样的,用户在看到鉴权相关文档后,他自知自己开启了认证鉴权模式,那么,很大概率就知道需要修改账号密码(难道不是吗,账号密码我都不知道,我开启鉴权如何登陆控制台)。 我的修复建议是:
|
|
对于如何判断 |
本来就不是给用户用的而是自己内部使用的机制,在使用文档上说明不妥。用户不知道才是正确的。 |
|
欢迎社区提供方案:
社区非常愿意接受。 |
|
我想到一个方法,即能勉强解决问题,又不影响现有机制。 当前这个识别是通过User-Agent 是Nacos-Server来判断,比较固定。如果修改成key和value都由用户配置是不是就好了。默认还是User-Agent 是Nacos-Server。 如果有用户非要放外网环境,就让他自己设置这个内容。 key value都是他自己设置的。只有设置的人和正确设置的服务端能跳过鉴权。这样对内网环境用户升级就没有影响。继续用默认即可。 |
|
你的解决方式类似Http Basic Authentication,确实可行。建议当设置了用户自定义的key value后,默认的失效,而用户不自定义的话,就使用默认的User-Agent: Nacos-Server 还有,其实我觉得最重要的是让用户(指的是使用nacos的开发维护人员)知道有这个机制。 |
如果采用这种方式, 这个kv对的数量需要讨论下, 是只允许有一对,还是可以有多种。 目前想法是只有一对,User-Agent: Nacos-Server只是一个缺醒值,用户设置的话就覆盖掉了。 |
我认为一对可行,若是多对kv的话,说不定可以给企业用户带来更好的自定义扩展 |
|
已经被RCE了,说不是漏洞? |
|
好像这个问题影响还是挺大的,希望早点修复,因为动态配置的修改可能会导致其它的关联服务被入侵,比如spring application.properties里面的jdbc连接被改成恶意地址(h2)等等,会导致关联服务被执行恶意代码 |
|
公网搜了一下 90+开了公网. RCE+DB密码.... 直接脱库 |
|
#4683 临时处理了一下。 后续版本再想方案彻底移除吧 |
ip白名单机制? |
|
这种安全话题不适合公开讨论吧,nacos 没有 security 的 mailing list 吗? |
|
fastjson |
|
never mind scandal and liber. NMSL |
从配置中心层面 apollo 都有权限验证,就算在配置了asm来脱敏一些信息, 我认为也需要鉴权。我算是明白了,为了快,安全都可以牺牲,fastjson是快了,nacos也是快了,结果裤子都被人脱了, |
我的理解Nacos就是属于一个内部型应用,不太会暴露在公网环境,请求基本都是可信环境的请求,目前的鉴权主要还是为了防止错用而影响其他应用,控制故障爆炸半径的思路去设计的。 这里的确是存在不少优化点,比如鉴权接口增加拓展性,以插件的形式接入,让社区安全大佬又更大的发挥空间,也让有强需求的用户能够对接他们认为安全的鉴权方式;2.0时候通过区分集群连接和客户端连接来进行不同的鉴权行为等。 主要问题点是大家对这个功能的理解不太一致,后续会在文档上补充说明。 |
是的 其实是应该做成可配置的。 1.4.1临时修改了一下,做成可配置的了。看前面的讨论也是这个结论。 主要还是社区前人实现的时候定位Nacos是一个内网应用,不太会暴露在公网环境,请求基本都是可信环境的请求。从设计上是防止正常内部使用者误操作导致其他人的故障的思路去设计的。 |
这里有个场景:
问题是,nacos的console设计,允许多用户、多角色、多权限,这是给人访问的,不是其他微服务,就算是内网,也是内部办公网可访问,办公网可访问的话,就一定不是可信的。这个问题的解决办法,就是分离console和config server。 |
其实很多暴露公网大部分都是大家测试用的,包括我们官网这个测试环境也是给大家测试, 大部分用户不会生产网暴露公网出来。 从我们角度看,哪个内部组件放到公网上一定都被黑客搞死的。 后面我们在产品文档中加强介绍生产网使用策略。 |
|
这种安全事件问题,在issues里面讨论真的好吗? >_< |
您这个大部分简直太负责任了 |
|
如果文档里面没有提及这个问题,并且没有明确写出「不推荐把组建暴露到公网」的鲜明文案,那么用「大部分用户不会生产网暴露公网出来」这种所谓的行业习惯来混弄过关,不是蠢就是坏。 |
@yanlinly 不是,老板,这个如上面所说,办公网/内网搞事也很危险的啊。不然哪天可能有用户直接上新闻,员工删 Nacos 跑路了 举个例子,B 员工上内网服务器,curl 一下带个特定 UA,就能拿最高权限。对于没有内控内审跳板机等安全机制的中小企业来说删了数据还查不出人,这样非常非常危险的。 再举个攻击面 不过如上面用户所说,这种事情,建议开一个专门的 mailing list 讨论最好。建议官方后面删除这个 issue 或者做脱敏处理。 |
回复1. 我指的是nacos的管理功能会通过nginx这种反向代理到公网上,那么在公网上肯定是需要做认证的,nginx不去代理服务的路径,就无法从公网去访问服务的数据或注册订阅,将管理和服务的功能区分开。我理解如果微服务能够集群在一起,这个集群的环境整体上是安全的,集群内部是可信的,不需要鉴权,增加鉴权反而降低了通信效率。退一步讲,集群环境中一个微服务出现安全问题,所有微服务都得跟着遭殃。 既然提供了管理界面,相信大部分人都会将这个功能通过公网暴露出来,方便自己对微服务进行管理。所以内部型应用是一个初衷,当带上管理的帽子,加以鉴权的功能,那么这个初衷就不成立了。 |
关于问题解决处理上面我已经回复我就不再次重复了。 我觉得内部组件不要暴露公网这个是一个常识。 我们是可以做好说明的,但是我不能阻断别人违背这个常识。 这个跟蠢跟坏没啥关系。 |
|
散了吧散了吧,越界了,受漏洞影响的用户,请升级到1.4.1版本https://github.com/alibaba/nacos/releases/tag/1.4.1,并且在conf/application.properties 配置中开启鉴权,以及启用新机制去避免被非法访问
恳请官方把我提的几个issue都做一下脱敏,或者删除吧,为何要通过issue提交安全漏洞,首先issue提交bug是惯例,其次最重要的是,除了温绍的fastjson、druid我可以找到ASRC报告以外,alibaba group中没有任何一个开源项目有security mail list。 |
|
还有,麻烦把这个issue也处理一下吧,最新机制的bypass |
忘了说,这个修复开启了也没用,#4701 |
|
这不是漏洞,这是后门。 |
|
严重同意@threedr3am 的观点,赶紧给删除或者脱敏。 |
@KomachiSion @yanlinly 麻烦项目管理员帮忙把issue内容进行一个删除 |
|
提一点,作为微服务框架这种平台性的东西,安全上最基本应当做到的就是”互不信任原则“,任何微 服务之间都应当假设彼此是不可信任的。这个公网内网没有任何关系。举个最简单的例子,如果平台上的一个低危低权服务出现rce漏洞或被实习生利用,是否整个平台上的服务都要跟着遭殃? |
安全问题不会因为删除而消失,只会因为删除而让受害者连排查问题都不知道从何做起、同时给能拿到0day漏洞的人更多可乘之机和提供更多信息不对等的机会。最好的方案是赶快发布漏洞声明、提交CVE、发布修复版本、利用github的security功能通知更多的使用者,而不是删除问题本身... |
受教了 |
|
服务间需要访问的那几个接口,做个url白名单不就解决了吗?何至于要用这种完全不可控的方法去bypass。。。 |
No description provided.
The text was updated successfully, but these errors were encountered: